-
-
Notifications
You must be signed in to change notification settings - Fork 702
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix cycles in Phobos #4493
Fix cycles in Phobos #4493
Conversation
|
||
shared static this() | ||
{ | ||
import std.encoding; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lots of folks would like to avoid pulling in std.encoding at all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have to say, the way this is done in std.encoding
is horrific. -- You register the encoding class name by string, and then it uses the runtime to look up the class info via search of that string. THEN it constructs it, and checks all the encodings that are supported (and then lets the GC collect it).
There MUST be a better way to do this...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, let's not forget that register
isn't thread safe, because the AA holding the encoding schemes is __gshared
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, technically it doesn't matter for shared static this, since there is only one thread. But the fact that it's not protected at later times is bad
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
register
is designed to be called by user code as well as Phobos, there's no guarantee that the user code will be in a shared static this
We might as well put |
Yes, the modules being assembled are not known until the linker is done :) |
Probably a good idea, but should be done separately (after this). |
@@ -2635,10 +2635,11 @@ abstract class EncodingScheme | |||
*/ | |||
class EncodingSchemeASCII : EncodingScheme | |||
{ | |||
/* // moved to std.internal.phobosinit | |||
shared static this() | |||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just delete these
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could if that's the consensus. The issue is that these really should go here. The example in the base class says to do it this way (and it will be fine for external libs to do that)
I honestly can't think of a better way to fix this, so I guess LGTM, as this is better than what we have now. |
Anyone else? I need this pulled in order to fix the cycle detection algorithm. |
✅ |
Auto-merge toggled on |
Ugly, but necessary, it seems. |
Thanks! Yeah, it's ugly. The best fix would be to be able to mark somehow that certain static ctors are trusted to be independent, but that requires dmd fixes (and a language change). |
@schveiguy This PR is causing test failures on my local machine, a 2015 Macbook Pro i5
Going to the commit before it
|
@JackStouffer I would try a make clean. You may have stale objects. It definitely works on Mac as autotester (and my system as well) shows. |
I did
I still got
|
Can you try a fresh clone ? |
@JackStouffer Can you try just making the entire thing instead of that one test? e.g. |
I observed the same (and more) errors on Travis at #4587 :/ |
It seems as if the static ctor in This may be a bug in the way the compiler does module info when you build individual modules. |
That passed. |
I had to workaround it for #4587 and thus reported it as a bug. https://issues.dlang.org/show_bug.cgi?id=16291 As said it can be easily reproduced on any Linux machine by either testing
or
|
How is this supposed to work? Nobody is referencing (importing) phobosinit at all, so the constructors will simply never run. |
@MartinNowak yes, this was my mistake. I'm trying to fix it, but running into other issues in |
And another regression caused by the fact that phobosinit is never run. |
Sorry for the mess, I should have noticed that the module is never used before merging the PR. |
- partially Revert "Merge pull request dlang#4493 from schveiguy/fixcycles2" - recreate processinit (and import it from std.process) to call std.process shared ctor w/o creating a cycle - keep it separate from phobosinit to not drag std.encoding into any binary using std.process
- partially Revert "Merge pull request dlang#4493 from schveiguy/fixcycles2" - recreate processinit (and import it from std.process) to call std.process shared ctor w/o creating a cycle - keep it separate from phobosinit to not drag std.encoding into any binary using std.process
Found while debugging #4467, the cycle detection code reverted to old broken behavior. See https://issues.dlang.org/show_bug.cgi?id=16211.
This is needed to pull the cycle detection code fix (dlang/druntime#1602).
The
std.experimental.allocator
offending static ctors can just be removed, because the referenced OSX issue has been fixed for a long time.The
std.encoding
cycle is a little more convoluted -- I overtookstd.internal.processinit
and renamed it tophobosinit
. I figured we can put general hacks like this in there. It would be nice to have a better way to fix this...